Description

When a Windows application includes windows.h before jpegli headers, the boolean type is defined as unsigned char (1 byte) by the Windows RPC headers. However, libjpeg-turbo's jmorecfg.h defines it as int (4 bytes) when HAVE_BOOLEAN is not defined. This causes a struct layout mismatch in jpeg_decompress_struct, triggering the size check error in jpegli_CreateDecompress.

Root Cause

The size check in jpegli_CreateDecompress (at lib/jpegli/decode.cc:560) compares sizeof(*cinfo) computed by the library against sizeof(struct jpeg_decompress_struct) computed by the caller. When the caller has windows.h included, the boolean field is 1 byte, but the library compiled it as 4 bytes, so the sizes differ and the function errors out.

Fix

Three files were modified:

lib/base/include_jpeglib.h

Added a #ifdef _WIN32 block before #include <jpeglib.h> that mirrors the upstream libjpeg-turbo fix from jconfig.h.in:

• Defines boolean as unsigned char (matching Windows convention) unless __RPCNDR_H__ is already defined (avoiding conflict with Windows RPC headers)
• Sets HAVE_BOOLEAN to prevent jmorecfg.h from redefining boolean as int
• Defines INT32 as signed int (not long) per Windows ABI convention, guarded against _BASETSD_H_/_BASETSD_H to avoid conflict with Windows headers
• Sets XMD_H to prevent jmorecfg.h from redefining INT16/INT32

lib/jpegli/decode_internal.h

Changed #include "jpeglib.h" to #include "lib/base/include_jpeglib.h" so this internal header also gets the Windows fix applied (previously bypassed it).

lib/jpegli/input.cc

Same change as above — now goes through include_jpeglib.h to ensure consistent boolean definition.

Testing

• The fix matches the well-tested approach used by upstream libjpeg-turbo in their jconfig.h.in
• On non-Windows platforms, the #ifdef _WIN32 block is a no-op, so there is no behavior change
• The __RPCNDR_H__ and _BASETSD_H_/_BASETSD_H guards prevent conflicts with Windows system headers
• All existing includes of jpeglib.h now go through include_jpeglib.h, ensuring consistent type definitions across all translation units

Fixes

Closes #128